When organizations need to have large-scale computer systems that hold mission critical information, such as purchase orders, financial information, etc., they usually resort to message transaction systems. Message transaction systems ensure that data is not lost if the system crashes, and also that data is not duplicated—such as ensuring that two copies of the same purchase order are not processed, etc. A transaction is an activity or a request, such as an order, a purchase, a change, or an addition to a database of information. Transactions usually update one or more files on a non-volatile storage such as a hard disk drive, and thus can serve as both an audit trail and a history for future analyses. A transaction can include one or more messages. A transaction is considered committed when all the messages of the transaction have been received and processed.
Message transaction systems can be batch systems. A batch is a set of requests that are processed together, often long after the requests have been submitted. For example, batch systems can execute the batches during non-peak periods, such as overnight, when usually requests are not being received as frequently. Typically, each batch is a sequence of transactions, and is executed sequentially, one transaction at a time. A batch system in the context of a message transaction system can be an off-line system, where transactions are collected throughout the day, for example, and then processed at night.
Batch systems can run in secure distributed environments, where there can be literally thousands of computers over which the batch “jobs” (viz., units of work running on the computer) are executed. Frequently, each computer has only limited access rights within the system, and usually does not have global rights to the entire system. This is problematic because a given computer which is given a particular transaction to commit (e.g., a particular batch job to execute) may not have all the access rights necessary to execute the job. That is, the dispatch computer, which is responsible for parceling out transactions for performance by the computers within the system, generally gives transactions to the computers as they become available, so that the computing resources within the system are leveraged. But the dispatch computer may parcel a job out to a computer that does not have adequate access privileges to execute the job.
Within the prior art, there are different ways to solve this problem, all of which are disadvantageous. First, a technician with sufficient privileges can manually start all the computers—that is, log onto all the computers—before the batch processing starts, such that all the computers are “live,” and therefore all resources are open and available to every computer. However, this is not practical, and can also pose a security risk, inasmuch as when the processing takes place, the system becomes completely open and thus unsecure.
Second, passwords for various accounts can be stored locally on the computers. Thus, when a computer needs access to a resource that it does not have privileges for, the computer can use the passwords it has at its disposal to properly access the resource. This, too, however, is a security risk, since a hacker breaking into the system may be able to obtain all the passwords for the entire system from a single compromised computer. Furthermore, there is a maintenance problem with this approach—passwords frequently change, such that the password stores throughout the system must be updated.
For these and other reasons, therefore, there is a need for the present invention.